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DESCRIPTION 
TECHNICAL FIELD OF THE INVENTION 

The present invention relates in general to computer 
language processors and, particularly to an extensible 
macro language . 

BACKGROUND OF THE INVENTION 

A macro is a set of commands that can be played back 
to perform a given task. Examples of these tasks include 
inserting a commonly used name and address into a word 
processor or executing a series of keystrokes to format a 
file. Tasks performed by macros are typically repetitive 
in nature allowing significant savings in time by executing 
the macro instead of manually repeating the commands. 

Currently, different applications allow users to write 
macros and scripts within the confines of the allowed 
domain, i.e., within the confines of the specific 
application. For example, word processors typically allow 
users to create a macro by recording series of keystrokes 
to be played back later. Other applications allow users to 
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create macros for retrieving and manipulating data within 
the confines of the applications. Thus, these applications 
include a limited set of macros, e.g., macro for recording 
keystrokes, a macro for retrieving data. The user is then 
5 typically limited to the macros provided by the 
application . 

Frequently, however, each user using an application 
has a unique set of instructions or commands that the user 

10 would like to include as a macro in the application which 
was not previously provided. Because the macros are 
typically hard coded into the applications or into the 
macro language included in the applications, the only 
available method currently available to include additional 

15 macros into the application is to hard code the new macros 
into the application by modifying the source code and 
recompiling it before the new macro can be used. Usually, 
however, this presents a problem because the user is not 
given an access to the source code of the macro language or 

20 the application to modify. Moreover, it would be a 

tremendous burden on the application developers to try to 
cater to each individual user's preferences by customizing 
the applications to include the macros that the user would 
like to have. 

25 

Therefore, it is highly desirable to have an 
extensible macro language that would allow users to modify 
and extend the language to include their preferences when 
using the macro language. Furthermore, it is also highly 
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desirable to be able to allow the users to extend the macro 
without having to modify or access the source code of the 
macro language since the source code is treated as a 
proprietary property not distributed to the users. 

5 

SUMMARY OF THE INVENTION 

To overcome the above shortcomings of the prior art 
macro language processors the present invention provides an 

10 extensible macro language that allows users to write new 
macro commands that include procedures tailored to the 
specific needs of the users without a need to modify any 
source code of the macro language processor. The 
extensible macro language is enabled to process the new 

15 macro commands by recognizing the new macro commands 
unknown to the language and associating the new macro 
commands with procedure calls stored in a registry, i.e., a 
repository, thereby allowing dynamic extension of a macro 
language . 

20 

In the present invention, a mechanism for dynamically 
registering new macro commands in a registry is also 
provided for allowing extensibility. To register new macro 
commands, the users may insert keywords representing the 
25 new macro commands and the associated codes or procedures 
in the registry for execution by the extensible macro 
language . 
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The present invention also defines a simplistic syntax 
for the extended macro language for recognizing the new 
macro commands for what they are without needing to know 
what functions they perform. 

5 

According to the goals of the present invention, there 
is provided a parser and a macro handler for processing 
macro commands not previously defined in the macro 
language. The macro commands not previously defined or 

10 undefined in the macro language refer to those macro 

commands that were not included in the set of commands 
available in the macro language at the time of release and 
distribution to the users. The parser analyzes keywords in 
a macro language expression and recognizes one or more 

15 keywords representing macro commands that were not 
previously defined in the macro language. The macro 
handler receives the keyword in the macro expression and 
retrieves from a registry of keywords, an executable code 
associated with the keyword. The executable code is run to 

20 process the macro command represented by the keyword. The 
registry of keywords may be augmented to include any 
keywords and associated codes for extending the macro 
language . 

25 Further features and advantages of the present 

invention as well as the structure and operation of various 
embodiments of the present invention are described in 
detail below with reference to the accompanying drawings. 
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In the drawings, like reference numbers indicate identical 
or functionally similar elements. 

5 BRIEF DESCRIPTION OF THE DRAWINGS 

Preferred embodiments of the present invention will 
now be described, by way of example only, with reference to 
the accompanying drawings in which: 

10 

Figure 1 is a block diagram illustrating the 
components of the extensible macro language of the present 
invention; and 

15 Figure 2 illustrates an example of a macro expression 

having an iterator macro. 

DETAILED DESCRIPTION OF THE INVENTION 

20 

The present invention is directed to an extensible 
macro language which may be extended dynamically in the 
runtime environment without having to rebuild and recompile 
the macro language. Although the extensible macro language 
25 may include a predetermined set of macro commands, the 
present invention allows users to add additional or new 
macro commands as desired. Figure 1 is a block diagram 100 
illustrating the components of the system for providing the 
extensible macro language of the present invention. The 
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parser 102 includes a grammar or syntax 104 that the parser 
102 employs to analyze and parse a given expression. As 
shown in Figure 1, the parser 102 receives a macro language 
expression 106 and parses the expression into components 
5 according to the syntax 104 of the macro language. The 

syntax used in one embodiment of the present invention will 
be described in more detail hereinbelow. Referring back to 
Figure 1, the parser 102 reads the expression 106 
recognizing certain tokens predefined in the syntax that 
10 indicate a presence of a new macro command. In this 

example, when the parser 102 encounters curly braces in the 
expression 106, parser 102 treats the keywords, for 
example, ^^property (name)", embedded within the braces as a 
new macro command. Moreover, the parser 102 recognizes, 
15 based on the syntax 104, that the ^^name" embedded within 
the parenthesis is a parameter to the new macro command. 
Other aspects of the syntax 104 may dictate that a string 
of characters outside any symbols to be interpreted as a 
literal string. Accordingly, the parser 102 breaks each 
20 element in the expression into components as shown at 108. 

A novel feature of the parser 102 in the present invention 
is that the parser 102 is transparent to the actual content 
within the tokens, i.e., curly braces. That is, as long as 
the new macro commands or keywords are embedded within a 
25 recognizable token, the parser 102 breaks the keywords down 
into components regardless of whether the keywords have 
been predefined in the macro language. Thus, as shown at 
108, the macro expression 106 is broken down into 
components according to the syntax 104 of the extended 
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macro language. The new keyword ^^property" is broken down 
as a token component 108a; the string ^^name" within the 
parenthesis is broken down as a parameter component 108b; 
the string ""likes" is broken down as a literal component 
5 108c; and the string ""pizza" is also broken down as a 
literal component 108d. 

As shown in Figure 1, the present invention also 
includes a macro handler 110, and a repository 112 having 

10 keywords and their corresponding executable codes. The 

executable codes may be stored in the repository 112 as a 
pointer to the actual codes 114 for execution. The 
repository 112 includes one or more keywords and associated 
codes, and may be dynamically modified, e.g., new keywords 

15 and codes added to it as need arises by a user of the macro 
language. The repository 112 in the present invention may 
be a simple file with a table of keywords and associated 
codes. Alternatively, a separate database may be used as 
the repository 112. 

20 

After the macro expression has been parsed into 
separate components as described above with reference to 
the parser 102, the components are then passed to the macro 
handler 110 for additional processing. For the token 
25 component having the keyword ""property" 10 8a, the macro 

handler checks a repository to the keyword ""property" . If 
found, the code associated with the keyword ""property" is 
retrieved and executed. In executing the code, the macro 
handler 110 passes all the parameters found in the macro 
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expression and parsed as parameters, to the executing code. 

The macro handler 110 does not need to know any other 
processing that may be performed inside the code itself. 
All that the macro handler 110 needs to recognize is that 
5 the '^property" is a keyword to be looked up in the 
repository 112 for its corresponding code^ and the 
specified corresponding code in the repository 112 to be 
executed with any parameters. The corresponding code is 
typically specified in the repository 112 as a pointer to 
10 the actual code itself 114 . 

After the proper execution of the code 114 specified 
in the repository, the macro handler 110 accepts one or 
more outputs, if any, of the executed code and places the 

15 outputs back into the macro expression in place of the 
keyword. Thus, in the example shown in Figure 1, the 
output of the code associated with the ^'property" with the 
parameter '"name" may be MARY. Consequently, the result of 
the extended macro expression {property (name) } likes 

20 pizza" at 106 is "'Mary likes pizza" as shown at IIG. 

A novel feature of the present invention is that the 
macro handler, like the parser, need not know anything in 
the code or what type of functions are being performed by 
25 the executable code. The macro handler merely provides an 
initiation into the executable code that is associated with 
the keyword. In an exemplary embodiment of the present 
invention, it is left up to the users to define exactly 
what the code should do, and consequently, therefore, what 
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command the keyword is to perform, thus providing a 
flexible and extensible macro language. 

In the above example, the output MARY may have been 
5 obtained in various ways transparent to the macro language 
For example, the name MARY may have been obtained by 
performing a search from the World Wide Web, or may have 
been obtained from a database using a query language, 
further illustrating the extensibility afforded by the 
10 present invention. 

The Lancruacre Syntax 

The syntax or the grammar employed in one embodiment 
15 of the extensible macro language will now be described in 
detail. The extensible macro language of the present 
invention includes a syntax (Figure 1 104) comprising 
literals, macros, comments and operator/scoping characters 

20 Literal 

The syntax in this embodiment treats all text outside 
of curly braces as a literal, and is emitted exactly as 
typed. Within curly braces, text inside double quotes is 
25 treated as a literal. Such a scheme allows for embedding 
of a literal within macro calls. Some examples of a 
literal are illustrated as follows: 

This text would be emitted just like this; 
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{'"So would this text"} 
Macros 

5 Macros include instructions to the macro processor, 

like procedures or functions in a programming language. 
According to the syntax defined in the present invention, 
all macros are embedded within curly braces. In one 
embodiment, the macros fall into two categories: procedures 

10 macros and iterator macros . 

Procedure macros are designed to perform some work. 
They may expand to a value; they may declare a variable; 
they may invoke a process. The actions performed are 
15 entirely specified by the designer of the macro. In one 

embodiment, the macros must, however, return a '"true" value 
upon successful completion of their task and a '"false" 
value upon failure. 

20 The following expression illustrates a string literal, 

followed by a macro call for getting the page number when 
printing : 

My Model Report - Page {HeaderPage} : Input 

25 My Model Report - Page 1 : Output 

In the above example, the HeaderPage is a macro 
defined by a user to extract a page number. 
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Iterator macros allow the user to traverse across data 
structures. Iterators are distinguished by the keywords 
^'begin'' and "end" that delimit a block of code following 
the iterator declaration. The code within the "begin/end" 
5 block is executed once for each iteration. When the 

iterator has moved across all objects in its pool, control 
breaks out of the iteration block and continues to execute 
a next statement in the macro expression after the block. 

10 The following block of macro expression illustrates a 

use of the iterator macro: 

{ 

Mylterator 
15 begin 

DoSome thing 

end 

} 

20 

In the above example, the procedure macro 
^'DoSomething" executes once for each element returned by 
the "Mylterator" macro. The curly braces surrounding the 
entire fragment indicates that all expression within the 
25 braces is to be treated as macro code. 


Parameters 
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The syntax defined in the extensible macro language of 
the present invention allows for both procedure and 
iterator to accept and process parameters. Parameters may 
include strings, or other macros. To distinguish 
5 parameters, the parameters are enclosed within parenthesis 
following the macro. Macros may accept variable -length 
parameter lists, as desired. The following illustrates a 
macro expression having a parameter "f oo'' : 

10 {MacroWithParameters (^^foo")} 

Control blocks 

In some instances, it is desirable to have a block of 
15 a macro expression to fail if any portion of it fails. The 
following example illustrates one such instance: 

{FirstName [Middlelnitial 'V] LastName} 

20 If there was no middle initial, the Middlelnitial 

macro would return a nil value or a fail value. In that 
case, the literal should not be printed. To 

accommodate for such conditions, the present invention 
includes in its syntax, square brackets that denote 

25 a conditional expression. Thus, if the macro within the 
square brackets fails, the rest of the expression in the 
square brackets is not emitted. In the above example, if 
the Middlelnitial failed for lack of value, the literal 
is not be printed. 
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The conditional blocks have internal scope, i.e., the 
failure of a conditional block does not affect the 
surrounding code. For conditions in a block to affect the 
outer block, the syntax additionally includes what is 
referred to as a propagating conditional denoted by angle 
brackets. If any macro within a pair of angle brackets 
fails, the block within the angle brackets as well as the 
next outer block fails. The following examples illustrate 
macro expression with a conditional and a propagating 
conditional : 
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{ Print " [ Print [ Fail ] ] } 
foo foo 

{ Print [ Print < Fail > ] } 

foo 


: input 
: output 

: input 
: output 


In both examples the ''Print" macro outputs the word 
20 ''foo''. In the first example, the failed macro in square 
brackets is contained within its block. Thus, the next 
outer block having "Print'' is executed as well as the first 
"Print", resulting in the output "foo foo". In the second 
example, when a macro within angle brackets fails, the 
25 failure is propagated to the next block having the "Print" 
macro. Thus, the next outer block with "Print" is not 
executed. Since this Print macro is contained within a 
pair of square brackets, the failure is contained in the 
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block. Thus, the first "Print" macro is executed, 
resulting in the output ^^foo" . 

Figure 2 illustrates an example of a macro expression 
5 including an iterator macro of the present invention. As 
described with reference to Figure 1, the keyword "ForEach'' 
is recognized by the parser 102 (Figure 1) as a macro, and 
the word ''Employee" is recognized as a parameter to the 
macro "^ForEach" . When the macro handler receives the token 

10 keyword ''ForEach" , the macro handler 110 (Figure 1) 

performs a look-up of the keyword '"ForEach" in the registry 
112 and executes the corresponding code. The code for 
''ForEach" macro, for example, may include instructions to 
perform commands found within the begin/end block of the 

15 macro expression for all sub-objects 204b, 204c in a given 
object 2 04 having the type of the specified parameter 
"employee". In this macro expression 202, another macro 
exists within the begin/end block. Accordingly, the macro 
handler 110 (Figure 1) performs a look-up of the keyword 

20 "Property" in the registry 112 and executes the 

corresponding code for each of the sub-objects 204b, 204c 
having employee type as specified in the "ForEach" keyword. 

The code associated with the "Property" keyword, for 
example, may include instructions to print the value of the 

25 type specified in the parameter of the keyword "Property", 
in this case, an employee name as specified by "EmpName" . 
Consequently, the result of the macro expression 2 02 is the 
output shown at 2 08, "Mary John". 
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The extensible macro language of the present invention 
is useful for customizing macros specific to the needs of 
individual users. For example, the extensible macro 
language has been interfaced with the UMA Model for 
5 retrieving various objects from the UMA Model, as desired 
by a user. The UMA is disclosed in a co-pending U.S. 

Patent Application No. (Atty. Docket #22074661- 

25535) entitled APPARATUS AND METHOD FOR MODELING TOOLS, 
filed on October 15, 1999, the disclosure of which is 

10 incorporated herein by reference in its entirety thereto. 
Appendix A includes a brief description of the extensible 
macro language of the present invention as used in the UMA 
Model and referred to as the UMA Template Language. The 
description in Appendix A explains one embodiment of the 

15 extensible macro language and should in no way be read as 

limiting the scope and capabilities of the extensible macro 
language to the descriptions contained therein. 

While the invention has been particularly shown and 
20 described with respect to an embodiment thereof, it will be 
understood by those skilled in the art that the foregoing 
and other changes in form and details may be made therein 
without departing from the spirit and scope of the 
invention. 
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CLAIMS 

What is claimed is: 

5 

1. A method for providing an extensible macro 
language comprising : 

analyzing a macro language expression; 

10 

determining based on a predetermined syntax of a macro 
language, one or more keywords in the analyzed macro 
language expression, the keyword representing a macro 
command not previously defined in the macro language; 

15 

retrieving a code associated with the keyword from a 
registry of keywords; and 

executing the code associated with the keyword. 

20 

2 . The method for providing an extensible macro 
language as claimed in claim 1, further comprising: 

extending the registry of keywords by inserting a new 
25 keyword and a code associated with the new keyword. 

3 . A system for providing an extensible macro 
language, comprising: 
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a parser having a predefined syntax to determine one 
or more extended keywords embedded within a macro language 
expression, the extended keyword representing a macro 
command undefined in a predetermined set of macro commands 
5 of a macro language; 

a keyword repository having one or more keywords and 
associated codes; and 

a macro handler coupled to the parser for receiving 
the extended keyword from the parser, the macro handler in 
response to the received extended keyword, retrieving a 
code associated with the received extended keyword from the 
keyword repository and executing the code to run the macro 
command represented by the extended keyword. 

4 . The extensible macro language as claimed in claim 
3, wherein the keyword repository is augmented to include 
new keywords and associated codes . 

5. A method for parsing a macro language expression, 
comprising : 

analyzing a macro language expression; and 
25 

determining based on a predetermined syntax of a macro 
language, one or more keywords in the analyzed macro 
language expression, the keywords representing macro 
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commands undefined in a predetermined set of macro commands 
of a macro language. 
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METHOD AISTD SYSTEM FOR AN EXTENSIBLE MACRO LANGUAGE 

ABSTRACT OF THE INVENTION 

5 

A method and system for an extensible macro language 
is provided. The system for providing the extensible macro 
language includes a parser and a macro handler for 
processing macro commands not previously defined in the 

10 macro language. The parser analyzes keywords in a macro 
language expression and recognizes one or more keywords 
representing macro commands that were not previously 
defined in the macro language. The macro handler receives 
the keyword in the macro expression and retrieves from a 

15 registry of keywords, an executable code or procedure 

associated with the keyword. The executable code is run to 
process the macro command represented by the keyword. The 
template language registry may be augmented to include any 
keywords and associated codes for extending the macro 

20 language . 
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Appendix A 


Overview 

The purpose of this document is to provide a brief introduction to the template language 
implemented in UMA. It assumes you have a working knowledge of the object/property 
metamodel of UM A, 

It is not intended to provide an exhaustive explanation of the architecture. UMA team 
members can provide you with such an explanation and they can direct you to many code 
samples that use this facility. 

The purpose of the UMA Template Language (UTL) is to provide scripting capabilities to 
any UMA-based application. These capabilities can be used for various features, 
including (but not limited to): 

• Macro expansion: Runtime expansion of code templates against the model. 
Examples include trigger code and stored procedures in OR*Compass, and Visual 
Basic and Java components in SQL-Compass. 

• Scripting: Execution ofa series ofcommands against the model. An example is 
the controller code for Forward Engineering in OR*Compass. 

The architecture of UTL is intended to promote its use in as many aspects of an UMA- 
based product as possible. This is accomplished by allowing the user^ maximum 
flexibility in tailoring the language to the specific needs of his product, while providing 
as much implementation support as possible and exposing mechanisms that allow reuse 
of new implementation code. 

To accomplish these goals, UTL: 

1 , defines a minimal syntax for the language; 

2, allows the user to write procedures and interators; 

3, provides a mechanism for registering the procedures and iterators in registries. 
Syntax Summary 

The following is abrief summary of the syntax of UTL intended to provide the bare 
minimum necessary to understand the implementation. More information can be found in 
the documentation shipped with OR^Compass LO. 

Template code consists of literals, macros, comments and a few operator/scoping 
characters. Currently, UTL views all code as strings: numeric values are described by 
their string representation; most macros evaluate to strings, etc. 


' In this document, **user" refers to the UMA application developer, not the end-user of the application. 
^ UTL 1.5, expected this fall, will also support numeric modes of operation that will provide better 
performance when dealing with numbers. This will be useful for features such as volumetric calculations. 


Literals 

In template source code, all text outside of curly braces is treated as a literal, and is 
emitted exactly as typed. Within curly braces, text inside double quotes is treated as a 
literal. The former allows large blocks of boilerplate to be entered, e.g. the body of a 
stored procedure. The latter allows you to embed literals within macro calls. 

Example: 

This text would emit just like this, 
{"So would this text."} 

Macros 

Macros are special instructions to the macro processor.., basically procedures. All macros 
are contained within curly braces. Macros basically fall into two categories: procedure 
macros and iterator macros. 

Procedure macros are designed to perform some work. They may expand to a value; they 
may declare a variable; they may invoke a process. The action(s) performed are entirely 
specified by the designer of the macro. The only constraint upon them is that they return 
True upon successful completion of their task and False upon failure. 

Example — the following shows a string literal, followed by a macro call forgetting the 
page number when printing: 

My Model Report - Page {HeaderPage} <=" Input 
My Model Report - Page 1 <=> Output 

Iterator macros allow the user to traverse across data structures. Iterators are 
distinguished by the keywords begin and end that delimit a block of code following the 
iterator declaration. All of the code within this begin/end block will be executed once for 
each iteration. When the iterator has moved across all objects in its pool, control will 
break out of the iteration block and execute the first statement after the block. 

Example — the following executes the procedure macro DoSomething once for each 
element returned by the Mylterator macro. Note the curly braces surrounding the entire 
code fragment.,. indicating that all code within is to be treated as macro code. 

{ 

Mylterator 
begin 

DoSomething 
end 

} 

Macros, both procedure and iterator, can take parameters. Parameters are strings, or 
anything that evaluates to a string, such as another macro. If a macro takes parameters, 
they are enclosed in parentheses after the macro. Since forward declaration of macros is 
not required, macros may accept variable-length parameter lists, if desired. 
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Exa272ple: 

{ MacroWithParameters {'*foo") } 

Control blocks 

Occasionally, it is desirable to have an entire block of temfplate code fail if any piece of it 
fails. An example would be where there was some boilerplate text followed by an 
optional value; if the value was not present, the boilerplate should not be emitted. 

Any code enclosed in square brackets is conditional: it will all fail if any piece of it feils. 
"Failure*' means that a macro will not execute and a literal will not be emitted. 

Example — if there is no middle name, the period will not emit: 
{ FirstName [Middlelnitial LastName } 

Conditional blocks hide their internal scope. This means that the failure of a conditional 
block has no effect on the surrounding code. Any code enclosed in angle brackets is 
propagating conditional: it will fail if any piece of it fails and it will propagate that 
failure out to the next block. 

The best way to distinguish these two types of blocks is with examples. In both 
examples, the Print macro emits the word "foo" and the Fail macro fails no matter what. 

Example of conditional block: 

{ Print " [ Print [ Fail ] ] } Input 
foo foo <=» Output 

Example of propagating condition block: 

{ Print [ Print < Fail > ] } <=" Input 

foo <^ Ouput 


Architecture 
LWMDataButler 

The desired capabilities of UTL are achieved using an object called a data butler. Data 
butlers are responsible for providing implementations for the macros encoxmtered by the 
macro processor when executing template code. When the macro processor is invoked, a 
data butler interface^ is supplied to it. Essentially, a data butler is a use of the Strategy 
pattern."* 


^ Interface defined in LWMDataButler.h 

* See Gamma, Helm, Johnson Vlissides, Design Patterns 
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This accomplishes the first goal of the language design. By providing different data 
butlers to the macro processor, the grammar of UTL can be configured for the application 
and task at hand. Each data butler implementation can accept a set of keywords (macros) 
appropriate for its task and reject keywords that are not acceptable. Further, a given 
keyword can be implemented in different ways by different data butlers, allowing 
template code to be ignorant of the underlying implementation. This is useful in allowing 
multiple products to work from the same templates when their underlying data models 
differ. 


The LWMDataButler interface has five entry points: 

// Handle procedure macro with no parameters 

virtual LWTBoolean SubstituteValue ( 

const LWTString & MacroName, 
LWTString & ExpansionValue) = 0 ; 

// Handle procedure macro with parameters 

virtual LWTBoolean SubstituteValue ( 

const LWTString & MacroName, 
LWMStringList & ParameterList , 
LWTString & ExpansionValue ) = 0 ; 

// Handle iterator macro with no parameters 
virtual LWTBoolean startlteration ( 

const LWTString & IterName ) = 0 ; 

// Handle iterator macro with parameters 

virtual LWTBoolean Startlteration ( 

const LWTString & IterName^ 
LWMStringList Sc ParameterList ) = o ; 

// Handle iterator macro iteration 
virtual LWTBoolean Nextlteration ( 

const LWTString & IterName } = 0 ; 


MCDataButlerl 

The second design goal of UTL was to provide as much functionality as possible to the 
user and to allow them to publish their own code for reuse. 

Since the metaphor of an UMA model deals with all data at a very abstract level — objects 
and properties — ^many grammatical elements of a template language can be written 
abstractly. These elements can be aggregated together to form the major portion of the 
language needed by any UMA-based product. The user could extend this base in the few 
areas that are product-specific. Ideally, the language should be extendable not only by 
the user, but by 'the end-user of the user's product. This is accomplished in our solution. 

There are two basic problems that are addressed by the solution: 

1, A mechanism is needed to share implementations. As new keywords are 
added, they must be published. 
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2. A mechanism is needed to control the context of a macro's execution. By this 
we refer to both the state of the UMA model at the time of execution, and to 
the specific object(s) or property(ies) the macro affects. 

To meet these criteria, a base implementation of a data butler exists in UMA. This 
implementation, MCDataButlerl^, provides mechanisms for defining the desired grammar 
incrementally and for managing contextual information in an UMA model. 

This implementation is a superset of the LWMDataButler interface. Though the 
LWMDataButler interface is exposed, the user need not concern himself with it when 
implementing a data butler. The implementation in MCDataButlerl accomplishes all that 
has been found necessary to do in terms of implementing the LWMDataButler interface. 

First, MCDataButlerl manages a registry of macro handlers. A macro handler is an 
object that knows how to perform a certain action, given a context. Conceptually, a 
macro handler is an example of a Command pattern.^ The data butler maintains a 
dictionary of macro handlers keyed by macro name. When the macro processor requests 
the data butler to handle a macro (e.g. via SubstituteValueQ ), the data butler locates the 
appropriate macro handler in its dictionary and delegates control to it. The macro handler 
processes the request and returns control to the data butler who simply forwards the 
return value (if any) and the success state to the macro processor. 

A macro handler exposes an interface that is used by the data butler for invocation: 

virtual LWTBoolean Execute ( 

MCDataButlerl * Butler, 
const LWTString & MacroName, 
liWMStringList * Parameters, 
LWTString * ExpansionValue) = 0; 

MCDataButlerl exposes an implementation signature for registering new handlers: 

void AddHandler( 

const LWTString & Macro, 
MCMacroHandlerBase * Handler) ; 

In order to implement a grammar, a user can construct an implementation of an 
MCDataButlerl and implement all required macro handlers. Alternatively, since the 
macro handler registry is a member variable of a data butler instead of a singleton, the 
user can subclass an existing data butlen This provides the user with all macros known to 
the subclass, plus those they develop. An example of this is the OR*Compass Forward 
Engineering data butler; it subclasses MCDataButler. The latter implements a wide 
variety of generic macros for creating objects, reading properties, iterating, constructing 
variables, etc. The Forward Engineering data butler implements one or two macros 
associated only with Forward Engineering (such as a macro for determining the correct 


* Implementation found in MCDataButlerlnterface.h 

* Op cit. Design Patterns 


execution command for a database) and ends up with a complete grammar for emitting 
DDL, 

Second, MCDataButlerl manages a context stack. The context stack allows a macro 
handler to know what object in the UMA model is being referenced when the macro 
executes. For example, the Property {) macro retrieves a named property from an 
object. The macro handler for Property ( > needs to know which object it should query. 

MCDataButlerl maintains a stack of object references and exposes an interface for 
pushing and popping objects on this stack, as well as for querying the stack. Macro 
handlers can query this interface to find out the context of their operation. 

MCObject * GetCurrentContext (void) ; 

void PopCurrentContext (void) ; 

void PushCurrent Context (MCObject * Object); 

Additionally, MCDataButlerl exposes a facility that allows MCObject iterators to manage 
the context automatically. Macro handlers for iterator macros can instantiate an iterator 
proxy. This is an object that automatically maintains the context stack for the iterator. 
Upon instantiation, it pushes the first object being iterated onto the context stack. Each 
subsequent iteration causes a pop and a push to occur. When there are no more items to 
traverse, the stack is popped, leaving it in the state that existed when the iterator was 
encountered. These iterator proxies are maintained in a stack of their own in order to 
manage nested iterators. 

Example — the following sample code shows how the Property macro would behave 
differently depending upon the context. Assume an entity named ''MyTablel " that has an 
attribute ''MyColumnl " and a second attribute *'MyColumn2. " Assume a second entity 
named *'MyTable2 " that has an attribute "MyColumn3, At the time this template code 
executes, we presume that the stack currently has the model on top due to some other 
code. 

{ <p Input 

PorEachC "UOEntities" ) 
begin 

Property ( "UPName" ) 
ForEach( ^^UPAt tributes" ) 
begin 

Property { ^UPName" ) 

end 

end 

} 

MyTablel MyColumnl MyColumn2 MyTable2 MyColumnS <=• Output 


